Contemporary databases, such as databases associated with enterprise applications, can include a tremendous number of entries (e.g., rows). These databases may be frequently updated, growing even larger in the process. Updating these databases and maintaining the ability to retrieve information from them can be challenging. In computer science, a data structure such as an “index” or a “heap” is used to store database entries. The index/heap may need to be recreated if it is altered frequently as a result of Data Definition Language operations, for example.
One conventional approach for altering an index/heap may be referred to as a catch-up approach. In such an approach, a copy of the database index/heap is made at a first point in time—a snapshot of the original, or source, index/heap is captured—and a new index/heap is recreated using the snapshot offline. In the meantime, changes continue to be made to the source version until, at a later point in time, those new changes are applied to the offline version. This process is repeated until, it is hoped, a point in time can be reached in which the number of changes since the last update of the offline version is small. At that point, the source version is “frozen” for a relatively short period of time. That is, during the period of time needed to apply the last (small) set of changes to the offline index/heap, the source cannot be changed. In this manner, the offline version is able to catch up with the source version.
The approach just described can be problematic if the number of changes does not get small enough for the source version to be frozen, preventing the offline version from catching up with the source version. To address this, a database administrator may choose to take the source version offline anyway, for a period of time that is long enough to apply the last (most recent) set of changes to the offline version. However, if the number of changes to be applied is large rather than small, then the source version may be frozen for a relatively long period of time. Thus, this approach carries a price of inconveniencing the customer served by the database because, while the source version is frozen, the enterprise applications that feed changes to the source may have to be halted. In a similar vein, a database administrator may choose to temporarily slow down those applications, to create a situation in which only a small number of changes are generated so that the source need be frozen for only a relatively short period of time. However, this too comes at a price of inconveniencing the customer served by the database.
In summary, conventional approaches for database management have problems because they may generate changes faster than the changes can be applied. Conventional solutions to these problems have their own problems. A new solution to these problems would therefore be of value.